Many organizations use configuration management databases to organize information relating to information technology devices. In particular, configuration management databases typically include a repository that stores various configuration items to describe physical and logical information technology resources. For example, in principle, configuration items may represent software, hardware, documents, physical containers, virtual containers, people, or any other physical or logical information technology resource that an organization may seek to manage via the configuration management database. As such, to map or otherwise model an information technology infrastructure, many organizations use configuration management databases to catalog various configuration items that may exist within the infrastructure in addition to other information associated with the configuration items (e.g., technical details, ownership, relationships to other configuration items, etc.). Broadly speaking, a configuration item therefore refers to the basic structural unit that a configuration management system uses to manage configuration item lifecycles through various processes and management tools.
One important concern relating to configuration management databases involves federation, where different management applications may be permitted to add information to the configuration management database or multiple configuration management databases are combined into a federated configuration management database solution. In particular, every configuration item within a configuration management database would ideally be associated with one and only one unique identifier, but different management applications tend to vary in how strictly unique identifiers are maintained depending on their purpose. Moreover, even when a standalone management application associates each configuration item with one and only one unique identifier, duplicate configuration items can arise in federated configuration management databases that provide one repository shared across multiple management applications. For example, one management application may use an IP address to uniquely identify a configuration item that represents a networked computer, while another may use a purchase order number associated with the computer. In another example, a particular server may have more than one fully qualified domain name (FQDN), which could result in multiple configuration items being created to represent the different fully qualified domain names. Furthermore, these problems tend to be exacerbated in networks that use the Dynamic Host Configuration Protocol (DHCP) if a management application uses IP addresses to identify the configuration items (i.e., because the IP address can and typically does change every time that a computer accesses a network via DHCP). Thus, integrating multiple configuration management systems into a federated configuration management database can easily lead to duplicate configuration items and a misrepresentative map of the configuration item network.
Although efforts have been made to reconcile information added to a configuration management database during federation (e.g., to reduce duplicate configuration items and ensure that the information relating to a particular configuration item was added accurately), the massive amounts of information typically stored in configuration management databases tends to require substantial computing power to determine whether the added information relates to an existing configuration item or a new configuration item. In this context, reconciliation refers to determining whether information associated with a particular configuration items applies to a configuration item already present in a configuration management database or whether a new configuration items needs to be created. For example, if different configuration items claim to have the same identity, then the different configuration items refer to the same physical or logical resource. However, existing reconciliation implementations have often been criticized because they tend to be slow, erroneous, and require excessive manual intervention. Moreover, the reconciliation implementations that have been attempted to date usually rely on simple matching algorithms that choose certain attributes to compare between different objects and distinguish identity, but these algorithms tend to produce many false negatives and false positives, not to mention undecided cases that require expensive and time-consuming manual intervention. In fact, due to the difficulties involved in reconciling the information in configuration management databases, accurate reconciliation has frequently been cited as a significant obstacle to implementing a federated configuration management database because interrelationships could be missed and potential consequences associated therewith remain unnoticed.